One conventional technique to debug a computer system (both hardware and software) is to connect a logic analyzer to a processor's address bus, data bus and certain control function signals. In this way, a development engineer can monitor the state of these parameters in real-time. A fundamental restriction of this technique, particularly in single-chip, very large scale integrated (VLSI) processors, is that only those signals available at the processor's external pins may be interrogated.
As processor design and software complexity has increased, the efficiency and capability of debugging such systems based solely on the information provided at a processor's external pins has decreased. To debug today's complex computer systems a development engineer needs to monitor a large number of variables (e.g., data, address, status, and control register contents), many of which are available only internal to the processor. Accessing these variables often requires that a number of debugging techniques be used.
In the breakpoint technique, the processor is run (i.e., a program is executed) at normal operating speeds up to a breakpoint instruction. At the breakpoint, program execution halts, processor states are preserved, and the development engineer then reviews many of the crucial parameters needed to debug the system. This technique, however, is fundamentally a static approach to debugging. Some problems that occur in complex modern processors, such as signal processors, often do not lend themselves to this stop- and-go style of analysis. First, the breakpoint technique is very slow. Second, it disrupts continuous, realtime system evaluation. For instance, breakpoint techniques often can not be used effectively to debug a signal processor designed to evaluate/process an analog signal because stopping the processor at a breakpoint disrupts the acquisition and processing of the signal itself. The processor can not, therefore, be evaluated as it performs its designed task.
A second technique, known as the code-substitution technique, a development engineer identifies program code associated with a variable, or variables, of interest. For instance, a program instruction that may modify the state of a processor's internal status register. A software routine is then written and substituted for the identified program instruction. The processor/program is then run at normal operating speeds. When the program gets to the point where the identified instruction would be executed, the substitute routine is executed instead. The substitute routine typically causes the processor to output the status of the identified variable(s) and other possibly relevant processor state information to a buffer memory. Afterwards program execution continues in normal fashion. Drawbacks to this technique include: (1) it adds extra cycles to the processor's operation which may disrupt the real-time evaluation of the computer system; (2) it is limited to the capture of variable information that is explicitly manipulated by the target program; mid (3) it has the problem of getting the captured data out of the buffer memory and to a debug system for evaluation by the development engineer.
A third debug technique is embodied in the IEEE Test Port and Boundary-Scan Architecture (IEEE standard no. 1149.1). This architecture specifies the use of special purpose hardware inside a processor which captures the processor's program counter at program execution discontinuities. This information is then output to an off-processor device through a serial port. Drawbacks to this technique include its limited capacity of information capture and its slow speed. Because the test port operates in serial fashion it is often not fast enough to keep up with real-time systems. This is especially true for real-time signal processors.
Another conventional debug technique is the use of in-circuit emulator (ICE) devices. While ICE devices typically provide access to more outputs than a processor's external pins, they are still quite limited. Further, because it is very difficult to design and build an emulator that is capable of executing at the same speed as the target system, this technique is often not capable of performing real-time debugging.
The aforementioned difficulty of monitoring, testing, and controlling (i.e., debugging) the operation of a computer system has increased significantly with the advent of modem single-chip pipelined computer processors. Modem processor designs are very complex, often utilizing a number of different internal data and address buses and registers that, because of pin count restrictions and operational speeds, are not available for off-chip monitoring. An apparatus and means for the real-time debugging of a complex processor (and software) that overcomes the aforementioned limitations is the subject of the instant invention.